A computer system includes a collection of hardware and software. The hardware for a computer system can include such diverse hardware as video cards, storage devices like hard disk drives, input devices like keyboards and pointing devices, and so on. The software for a computer system can include an operating system, which is the master computer program for the computer system, as well as application programs that run in the context of the operating system. The application programs typically access the hardware for a computer system through the operating system.
The operating system includes a number of software components, referred to as device drivers, which are specifically developed to communicate with particular hardware. For instance, for a number of different kinds of video cards and storage devices, there may be a number of different device drivers. The operating system passes usually standardized requests for communication with the hardware to the device drivers. In turn, the device drivers translate those requests into the specific manner by which their corresponding hardware expects to receive communication.
Device drivers, as well as the other software of a computer system, usually need to store some data within the memory of the computer system. A device driver therefore allocates needed memory through the operating system, and the operating system sets aside this memory for use by the device driver. When the device driver is finished using the memory that has been allocated to it, the driver sends a notice to the operating system. The operating system in turn allows this memory to be freed, so that it can be allocated for other software of the computer system as needed.
Versions of the Microsoft® Windows® operating system, available from Microsoft Corp., of Redmond, Wash., as well as versions of other operating systems, allow device drivers and other software to allocate memory in at least two different ways. First, a device driver may when initialized request that blocks of memory be set aside for its future use, where these blocks of memory are each a multiple of a same size of memory that will be later requested by the driver. Such blocks of memory are referred to herein as lookaside lists.
For example, a device driver may request that ten or more entries, each sixteen bytes in size, be set aside. The collection of these entries is referred to as a lookaside list. Importantly, within a given lookaside list, each entry has the same size. When the device driver later needs to use memory of this size, it requests that the operating system return it a pointer to an unused entry within the list. When the driver is finished using the memory, it notifies the operating system that the entry can be again denoted as being unused.
Second, a device driver may dynamically while it is running request that memory of any desired size be allocated from a memory pool. The memory pool is a collection of currently unused memory throughout the computer system. When fielding a request for memory of a given size from the memory pool, the operating system examines what memory is available within the pool, and returns to the driver a description of where to find this memory, such as a pointer to the memory. The operating system may have to collect a number of discontiguous memory segments in order to satisfy the given size of a memory request.
Lookaside lists have the advantage of satisfying memory requests from device drivers quickly. This is because the memory of a lookaside list has already been set aside by the operating system. The operating system therefore simply has to return to a device driver a pointer to an unused entry within the list. Disadvantageously, however, lookaside lists require that memory be set aside when the driver is initialized, regardless of whether the driver will actually use the memory. The driver must, therefore, a priori determine what types of lookaside lists it will require in the future.
Furthermore, a lookaside list can only be used to satisfy more requests requesting an amount of memory equal to or less than the size of each entry of the list. Using a lookaside list with entries sixteen bytes in size, for example, can be used to satisfy requests for memory no greater than sixteen bytes. Additionally, if such a lookaside list is used to satisfy a memory request less than sixteen bytes in size, sixteen bytes will nevertheless be allocated, wasting one or more bytes of memory.
Satisfying memory allocations from the general memory pool of a computer system has the advantage of being able to field memory requests of any size. Because memory is not allocated in this way until a memory request has been received, no memory is wasted by being set initially aside, and the exact amount of memory requested can be allocated. Disadvantageously, however, the operating system may exact a performance penalty by having to locate sufficient free memory, even if segmented, to satisfy a particular memory request.
Therefore, both ways of satisfying memory allocation requests have their uses. A device driver knowing that it will likely be requesting the same amount of memory a number of times should initiate a lookaside list for this amount of memory. For other memory needs, however, the device driver may allocate memory from the memory pool, especially for amounts of memory that have sizes that are not likely to be repeatedly requested by the driver.
A disadvantage with current operating systems, such as versions of the Microsoft® Windows® operating system, is that the developer of a device driver has to hard code into the driver the ways in which the device driver will allocate different sizes of memory. For example, the operating system may provide one type of call to allocate memory using a lookaside list, and another type of call to allocate memory from the memory pool. The developer of a device driver must therefore employ the appropriate type of call to allocate memory in the desired manner.
What this means is that if the developer later decides that a certain kind of memory allocation would be best handled by a lookaside list instead of from the memory pool, or vice-versa, he or she has to recode and recompile the device driver. Many times the developer will want to test the performance of a device driver to determine whether a lookaside list or the memory pool is the best source for a given memory allocation. Therefore, the developer may have to recode and recompile the device driver many times in order to maximize driver performance. Even then, performance can vary depending on the specific computer system on which the device driver is run, and there is no easy way to tune memory allocations by a driver once it has been dispatched into the field.
Furthermore, using more than one lookaside list, where each lookaside list is dedicated to satisfying memory allocation requests of a particular size or amount, also requires undue developer attention. When allocating memory using a lookaside list, a device driver usually has to specify the specific lookaside list from which the memory is to be allocated. If the wrong lookaside list is specified, either too much memory will be allocated, or more seriously, insufficient memory will be allocated, which can cause the computer system to crash.
For these and other reasons, therefore, there is a need for the present invention.